Community

This is a very good 'how to' post. There is more to payments, however, than card acceptance which is what this post is largely about.  What about issuing cards, or working with bank accounts, whether through open banking or even directly issuing payment accounts.  As the post states, it is all about anticipating and responding to pain points faced by online businesses.  With the increasing number of digital innovators, the payment industry is trying to address the pain points faced by new entrants who have an urgency to go to market as well as managing tight cash reserves.  There may be go-to solutions for card acceptance but it’s much harder to find solutions for any other payment process besides card acceptance.

Perhaps a more viable approach would have been for PSD2 to stipulate robust interoperability and data standards available to all TPPs, plus minimum banking standards of conduct for disputed transactions with a body (EBA?) as arbiter.  That would have made it so mch easier for PoS providers to invest. PSD3 maybe? 

Your point about timing is well made, Paul, but also note that PSD2 will only enable access to licensed third-party providers rather than the long tail of developers and innovators. 

In addition to enabling acces for innovators with deeper pockets, OPC is also looking to support the long tail of developers by inviting an initial ‘founder members’ group of financial institutions and payments processing vendors to the OPC.

I couldn't agree more. One approach that the financial services industry seems to have overlooked up to now is Model-Driven Engineering which involves assembling models (in our case Payment Models) from such Lego blocks  (which are called Paylets). At the Open Payments Cloud hackathon in London this weekend, 9 teams of mostly non specialist developers were able to develop a range of applications that rely on complex payment flows simply by relying on a model-based approach.

I don't buy the bottom up approach because it is simply too hard for most banks and is unlikely to happen any time soon.  Banks are better off doing two things first: use a cloud based approach to new services so they can be nimble and not shackled by the legacy architecture, and create middleware overlays over their legacy systems.  Both these approaches will enable them to publish APIs in a practical and cost-effective way.  Once front end services (whether delivered via APIs or via user interfaces) are established, banks can then take the time (and pace their expenditure) to gut out their legacy systems and replace them with the kind of structured architecture that Hans is advocating.  

I welcome Hannah Nixon’s comments and share the view that more needs to be done to create the environment for payments innovation. As a technology provider to banks and financial institutions, my company Ixaris has a direct role to play in enabling that change. A few weeks ago, I shared a platform with leading payments industry experts at PayExpo in London, where the audience’s appetite for open payments access was unequivocal, but there was no clear view on how this might come about.

That thinking is, in part, why Ixaris has launched the ‘Open Payments Ecosystem’ project, with funding from the EU. The project will deliver the technology platform that allows banks to collaborate with developers, small and large, to provide access to their infrastructure in a safe environment to enable an explosion in the development of payment applications addressing the diversity of customer needs.

We believe such a platform, an exchange in essence, is fundamental to the success of open payments.

There is a reason why prepaid can be more vulnerable: many prepaid programmes are part of relatively complex (compared to, say, a debit or credit card programme) solutions are put together involving more than just card processing and typically involve a number of external providers for, say, card loading, and external parties in operational roles, such as employers loading the cards for payroll payments.  

The breadth of application is what makes prepaid compelling but also challenging.  See my blog post for more on this https://www.finextra.com/blogs/fullblog.aspx?blogid=8789

As bank CIOs attempt to open up access to their systems by providing clients with APIs for their data and transaction processing systems, they will find that the power they can offer through APIs will be restricted, both in functionality and client access. This is because transactional facilities by their nature come loaded with risk management and regulatory requirements that financial institutions cannot simply offload on to clients.

 The provision of API access to raw transactional systems is just not feasible.  One solution is to create an application layer between the processing systems and the public APIs to provide business logic – typically in the form of purposely-engineered payment programs – specifically designed to offer valuable services that can be effectively overseen and controlled from a risk and compliance perspective.